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^^^^M ^^^^r t's funny the 

^^^^^^^^ way things work 

^^^^^ out. I would never 
have imagined that 
someday I'd be a proponent of the 8051 
tfchitectuze. But, in lig^t of die work 
I've been doing lately with a vanety of 
8(B1 demxti^, tins mi^t be exactly 
the way I'm comity across. Quite 
frankly, I'm not entirely comfortable 
with the situation. 

I still remember my first encoun- 
ter with the 8051. 1 immediately 
recognized its utility as a Boolean 
processor and was quite impressed 
with the ease with which it handled 
bit-oriented I/O. At the same time, I 
was appalled by the seemingly random 
arch^Knuie axid theabmce of some 
rather hmd^i^tal ias^icticaa. 
These idiosyncrasies continue to irk 
me and ^ipear all die more enipnatic 
in light of recent microcontroller 
advances. 

Still, it pays to remember that 
silicon was a much more precious 
comroodity at the time the 8051 was 
developed than it is today. Obviously, 
the seemingly arbitrary exceptions and 
bizarre architectural quirks was the 
result of gut-wrenching decisions 
made to bring the processor's {ffin^al 
features in line widi a Gonatniined 
silicon budget. It's not an uncommon 
problem. I'm sure the consequences of 
those unpleasant decisions were not 
taken lightly. 

Although the mechanics of 
crafting silicon have changed, the 
fundamental aspects of doing business 
remain the same. And, this is the key 
to the puzzle since this is, ^er all, a 
business venture and not a sdlence f^ 
proiect. As a case in point, consld^ 



how this same scenario has xc^Uyed 
over the years. 

More recently, the same tough 
choice between price, performance, 
and features was played out with yet 
another strange, but extremely 
successhil microcontroller — the much 
maligned, Microchqi PICI6C54. To 
me, &is processor is the c^toxne of 
business sense winning out aver 
technological constraints. 

The thing doesn't even have an 
interrupt. Although technically a no- 
brainer, adding an interrupt would 
have resulted in totally blowing the 
target price. Talk about tough choices. 
As it turned out, the chip's many 
deficiencies were each countered by a 
combination of skiUfiU marketing and 
imaginative tedmical support. They 
even amvinced a si^fuendy large 
number of enffoit&s that they really 
didn't need that intmupt after all! 

Both the 8051 and the 16CS4 
architectures have established them- 
selves in their respective spheres of 
apphcation. As Microchip develops the 
PIC series into larger, more capable 
devices, it's inevitable that the 
architecture's basic simpHcity has 
become somewhat obscure. 

Ironically, the 16C54's big 
Ino^m are carting to iooka lot like 
30319, a ratte questionable t^stinc- 
ticm. If 8 also a dubious arena to 
compete in since it is well-served by 
some firmly established controllers. 
To me, the original 16C54 is still the 
soul of the PIC family. Warts and all, 
this is the part I turn to when I need to 
implement bare-bones f unctionaUty 
and ail I sMeM is a $2 ck^. 

VraAP IT UP 

Formerly, using a higiicar-level 
laa^^o^ on SCSI-class {nrocessors was 
consii^ed a disputable practice at 
best. After aU, the basic architecture 
has Uttle enough real stack space to 
begin with and no slack manipulation 
capability at all — obviously, a major 
drawback with a stack-oriented 
language. Combining these handicaps 
with a meager instruction set and all 
those overlapping code, data, and bit 
segments, it's no wonder that many 
viewed u^lng code generators on such 
mi0c» m nothing more than an 



This little 
chip is 
Vi ~ essentially 
1 a flash- 
based 8051 with some 
extra RAM in a 20-pin 
package. True, it does 
possess fewer I/O pins, 
but it provides all the 
peripherals and 
functions of a standard 
8051. 
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interesting diversion widi Utde 
practical consequence. 

Evidently, in spite of these 
obstacles, compiler developers have 
mand^ed to prei^. At^uaUy, it coidd 
be argued that it is because of these 
obstacles diat diey have been so 
successful. Itie fact is, placing a good 
code generator between such an 
architecture and yourself isn't that bad 
an idea. When I'm writing code, I don't 
mind dropping to the machine level 
when it's necessary or expeditious. I'm 
also well aware of how counterproduc- 
tive it is to remain at that level any 
longer than necessary. 

An analyses of the situation 
reveals that some of the most popular 
embedded-C compiler implementa- 
tions run tm smne of the more "diffi- 
cult" processors. This could be 
constmed as something of a paradox. 
The impHcation seems to be that these 
popular, although irregular, processors 
assume a level of anonymity through 
the insulating effect of the language 
compilers. 

From this, it follows that selecting 
an appropriate architecture should be a 
relatively strai^tforward and rational 
exercise. This might be true if a typical 
embeddni progi^n (^RiM be coded 
entirely usmg a higher-level language. 
That this is not die case, especially 
with 8-bit processors, is evident by the 
continued popularity of older architec- 
tiures Uke the ones I've been describ- 
ing — so much for rational thinking. If 
it looks to you like a case of the tail 
wagging t^ do^ tfam yffli're jxat 
alone. 

The fact is, as any embedded 
developer well understands, portable 
:ode is wmediuig is ortremely 
elusive and <Wciilt to aixomplish in 
most embedded applications. Usually, 
system I/O tums out to be such a big 
part of the overall picture that it is the 
primary concern. 

And, regardless of "proper" coding 
techniques, embedded programs are 
often laced with timing dependencies 
rhat rely on the execution times of 
■ arious pieces of code. When doing 
this type oi programming, the bottom 
line is that you have to Imow wl^n to 
get down to the maehine levd and you 
must ha^re a ^od usderstanding M ihe 



quality of code your compiler is 
generating. 

Still, in spite of all the complicat- 
ing issues, the productivity gains that 
can be realized from using a higher- 
level language offer a compelling 
incentive to rethink the way you've 
been writing ycRiUr embedded programs. 

The benefits of using language 
compilers can be perceived ^lEeximtly 
depending on your particular needs. 
Minimally, an efficient compiler can 
function as a sort of stylized assem- 
bler. This is especially true of the C 
programming language which affords 
excellent control of low-level func- 
tions. The incentive for this category 
of usage is pretty strong with many of 
the more limited omtrolleis and 
processors. 

Recently, some of the most 
d^cult C implementations have been 



realized on resource-starved control- 
lers such as the PIC16C5't. Frankly, 
when I first found out that engineers 
were actually seeking C compilers for 
the 16C54, 1 was a bit baffled. I mean, 
with a two-level stack, 512 words of 
program memory, and a few dozen 
bytes of read/write storage, it didn't 
exactly seem like a good fit. It looked 
like the compiler's overhead alone 
eonld swamp the processor's meager 
resources. 

It tums out that there are some 
very smart software people and now 
there are a number of C compilers 
available for these mmuscule proces- 
sors. Reports from the field indicate 
that this stuff really works. I haven't 
tried one yet but, having done a couple 
of projects involving the 16C54, I'm 
very ^t^ested. You see, one of ilie big 
attracticms of a language compiler for 
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me is its ability to handle many of the 
tedious programming details. And, 
there are many of these indeed when 
working with very small processors. 

Put another way— if it's ugly, wrap 
itupl 

LISTEN TO YOUR CUSTOMERS 

Recent evolutionary trends have 
involved enhancing "standard" 
processor architectures. For hetter or 
worse, the 8051 is now perceived as 
standard indeed. In recent columns, 
I've shown how this basic architecture 
has gained in performance and capabil- 
ity while retaining its standard 
footprint and pinning. 

There's also been a trend to 
downsize the sichitectuie. Downsizing 
has led to a loss of some capabilities, a 
reorganization of the fundamental 
processing core, and a reduction of on- 
chip memory. The high end has been 
weU served by a variety of capable 
derivatives. The low »id until recently 
has beea...well, the low end. But 



finally, someone has introduced a very 
small 8051 that doesn't give 19 any of 
its fundamental featiues. 

The new, flash-based ATg9C20Sl 
from Atmel is a welcome addition to 
the 8051 family. Mote than just 
another scaled down 80SI, this 
processor is a full-blown 8051 housed 
in a 20-pin package. All the standard 
8051 peripherals have been retained 
including two 16-bit timers along with 
their gating controls and associated 
interrupts, two external interrupts, and 
a full-duplex hardware UART. This is 
in addition to 2 KB of flash program 
memory and the standard 128 bytes of 
internal RAM. 

It may not seem like a big deal at 
fim, but it is the inclusion of the full 
128 bytes of internal RAM that opens 
up substantial opportunities for using 
this part with standard commercial C 
compilers. While using a compiled 
lanRuuKC is certainly an option with 
some of the more restricted 8051 
dMvatiVes, dibigs naturally get quite 



limited with the 64 bytes of RAM 
most of these smaller chips offer. And, 
if you're worried about code efficiency, 
the AT89C205 1 specifies an operating 
frequency from DC to 24 MHz. This 
gives you the elbow room to handle 
any reduction of efficiency that results 
from using a code compiler. 

Another area that competitive 
products have consiatratly ignored is 
the inclusion of a haidwaie UART. 
Althoui^ many of the competing parts 
offer hardware-assisted PC interfaces, 
it's obviously of little consolation 
when you have to provide for standard 
asynchronous communications. 

From where I sit, the outcry for a 
hardware UART has been long, loud, 
and clear. Needless to say, thus far, the 
semiconductor manufacturers have 
been totally imreceptive to what users 
have been calling for. Theii response 
to diese requests has axufly been to 
either say that you really don't need it 
or to suggest nmning one entirely in 
firmware. I'm surprised this "what 
we've got is what you need" mentality 
has prevailed as long as it has. 

As a result of this attitude, 
manufacturers have left themselves 
wide open, jeopardizing a significant 
market share. If the .'\T89C205 1 
offered nothing more than just a 
hardware UART, its success would be 
ensured, tlie fact is it's got a lot more 
than that going for it. Rgaxe I shows 
the contents of diia 20-pin fsoceaaor in 
block form. 

I LIKE PC 

The AT89C2051 possesses a full 
8051 architecture, it iust happens to 
have fewer I/O pins. Obviously, to 
design a general-purpose embedded 
computer around such a device, it's 
necessary to conserve these I/Os. The 
most efficient way to hook up a lot of 
peripherals using just a couple of lines 
is over the PC bus. 

At first, it might seem diat not 
having any hardware PC support 
might prove to be a trujor liability in 
what essentially amounts to an FC- 
based computer. But, with the excep- 
tion of some very specialized applica- 
tions, it is not a problem at ill. 

Remember that FC detines a 
syaehnmous protocol ^t is capable ol 



78 MiismMn«y19M Ckmal Cellar INK 



running all the way down to 
DC. With the AT89C2051's 
complement of internal and 
external interrupts, it's easy 
to arrange time-critical 
processes to mn entirely 
under interrupts. This lets 
you bit-bang the PC and still 
stay live to service your real- 
Qune opezttioos. 

Obviously, diis i* lumiy 
you don't have friwn bit- 
widdling asyndmmoas 
communications, which by 
definition must adhere to 
relatively strict timing 
constraints. Sure, you can 
run asynchronous communi- 
cations in the interrupts, but 
there are serious limiutions 
to the maximum fait me you 
can reach. 

Some PC peripherals 
come prepackaged and ready 
to go. The small multifunc- 
tion card shown in Photo I 
illustrates a number of such 
useful functions. Figure 2 depicts the 
card's schemaric. The l/O-related 
functions include four single-ended or 
two differential 8-bit analog inputs, 
one 8-bit analog output, and eight 
digital 1/0 points. 

The card also provides a real-time 
clock-calendar timer with 256 bytes of 
RAM, a dedicated 256 bytes of RAM, 
and 512 bytes of E^OM. Hie RTC 
and RAM are backed using 
a BR 1225 Uthium coin cell 
that is also contained on 
the card. The card, includ- 
ing connectors, measures 
only 1" X 3". If your appiica- 
'lon doesn't need these 
t unctions, then simply 
don't load the card. PC, 
especially a firmware-based 
implementation as used 
here, carries very little 
hardware overhead. Even 
the requite poU-up 
resistors aie loeaud on the 
■ird. 

Higher-level I-C 
Itinctions are realized using 
a combination of FC and 
logic ICs. Using a couple of 
PC-to-paiaUel coQveiters 
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and some suppon logic, a 4 x 20 LCD 
and a 4 X 4 keypad can be supported 
using the same two 1/0 lines. The 
control card for this peripheral system 
attaches almost mvisibly beneath the 
standard 4 x 20 supertwist LCD panel 
as shown in Photo 2. This arrangement 
leaves a niunber of general-purpose I/O 
lines fteetodnveabeeper, LEDs, and 
other indicators. 
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PROCESSOR I/O 

So far, the I/O devices I've de- 
scribed encompass ail the peripheral 
functions a very small embedded 
computer might need. The beauty of 
this arrangement is that, although the 
39C2051 has only 15 I/O pins to begin 
with, after accommodating aU these 
functions we are still \t£t 13 for 
general usage. These I/Os can be 

directly tested and set by 
the processor and are 
therefore very fast. 
Among these general- 
purpose I/O bits are two 
external interrupts, 
receive-and- transmit 
connections to a full- 
duplex UART, and the 
gating signals ior the two 
internal 16-bit timers. 

Althou^ the on-chip 
I/O lines are for dse most 
part 8051 compatible, 
there are some impOTtant 
differences. Refer again to 
Figure 1 . You can see the 
familiar 80Si pinout 
nomenclature has been 
preserved. From this 
f^uie, you can also see 
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dutpins Pl.O and Pl.l are designated 
as analog inputs. These high-imped- 
ance inputs serve as positive (AINO| 
and negative 1AIN1| inputs to the 
built-in precision analog compaiator. 
F3.6 is not available enemally and 
instead takes the output of this 
comparator as Its input. To facilitate 
intetfadng to leal-wrarld losds without 
the need for external buffeia, ports 1 
and 3 aie nted to sink a full 20 mA 
when tunning at 5 V. 

MAKE SENSE? 

If you accept that the peripheral 
mix I've described for my system is 
not unusual, then perhaps 1 can offer 
some insight from my own ei^Kri- 
ences on issues like code portability, 
code reuse, and the enduring success 
enjoyed by the 8051 architecnue. In 
this context, I will also elaborate cm 
why I feel the 89C20S1 is such a 
significant processor. 

Simply put, the PC peripheral set 
I've described has served me well in a 
variety ot conti^^urations on a variety 
of host systems tor a number of years. 
I've developed a fair amount of C code 
to support these functions, but the 
main low-level drivers are all, of 
necessity, written in hand-tweaked 
assembler. 

This in itself represents a signifi- 
cant investment of time and effort. To 
this, of couite, you must add the 



"standard" overhead of the trade. This 
overhead includes such things as 
interfacing low-level code to the 
compiled code (usually quite different 
for each compilei you use); debugging, 
testing, and validating functions; 
documentMion) and continuing 
support. Underestimating these 
associated tasb can have a ddetoiom 
effect on your continued success in 
thisfieldl 

Electronics means different things 
to different people. To those of us that 
have bills to pay, it's a business. In this 
context, the bottom line revolves 
aroimd spinning off appUcations. 
Efficiency in doing so is what can 
make or break it. Sun I could code 
a new set of low-level drivers for a 
diffoent processor in a relatively short 
poiod (disregarding the overhead of 
coutsel. And, if I had to, I could take 
all that C code and rewrite it in 
assembler if the processor I was using 
didn't have the horsepower to handle a 
compiled language. 

Individually, these are fairly small 
tasks. It's only when you look at the 
overall picture that it becomes evident 
that a significant amount of time can 
be spent on these tasks. And, I haven't 
even touched on thinp like legenetat- 
ing all my intermpt-driven communi- 
cation routines, timer-captuie func- 
tions, and the like. There comes a 
point virhen you have to ask yourself 



where you want (or can afiordi to 
spend your developmoit time. 

EMB EDDED TOOLS 

I'm sure if s obvious I have more 
than just a passing interest in the new 

Atmel processor. Next month, I'll cut 
through the fluff and devote my 
attention to the design and develop- 
ment of a very small, general-purpose 
computer based on the AT89C2051. 

Havmg defined the 1" x 3" form 
factor for the PC peripheral card, I will 
use the same (ootpxint for the main 
processor card. This card will conuin 
die 20-pin, fbudii-baaed processor; an 
RS-232 and RS-48S interface; power 
supply; and prototype area. 

The main focus of my column, 
however, will be the associated 
development system for the 
AT89C2051. In this respect. Til also be 
covering the AT89C51 flash-based 
processor that, with some hardware 
assistance, emulates the AT89C2051. 
The system works with a variety of 
target systems since it uses a uandud 
umbilical cable hookup. 

Of course, once you get an 
plication up and running, you'll 
want to program the AT89C205I flash 
memory. This will be accomplhhed 
with the built-in flash programmer 
contained right on the development 
system. As usual, I'll be calling on my 
esteemed colleague, Dave Dunfield, for 
his fine PC-hosted development tools. 
I'll be using his simulator and remote- 
debugging software to round out the 
development system. Frar code genera- 
tion, I plan to use his Micro-C and 
assembler pro^icts. 

John Dybowski is an engineer in- 
volved in the design and manufactuie 
of embedded controUers and commu- 
nications equipment with a special 
focus on portable and battery-oper- 
ated instruments. He is also owner of 
Mid-Tech Computing Devices, lohn 
maybeieachedat 1203) 684-2442 or 
at iohn.dybowski@cm:dhir com. 
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